the error completely and there is no need to take any other
action for the error. If it returns non-zero it means _p_r_o_c
was unable to handle the error.
If a value of NULL is specified for _p_r_o_c, all matching
errors will be ignored: this will produce the same result
as if a procedure had been specified that always returns 0.
If more than more than one handler matches a particular
error, then they are invoked in turn. The handlers will be
invoked in reverse order of creation: most recently
declared handler first. If any handler returns 0, then
subsequent (older) handlers will not be invoked. If no
handler returns 0, then Tk invokes X'es default error
handler, which prints an error message and aborts the
program. If you wish to have a default handler that deals
with errors that no other handler can deal with, then
declare it first.
The X documentation states that ``the error handler should
not call any functions (directly or indirectly) on the
display that will generate protocol requests or that will
look for input events.'' This restriction applies to
handlers declared by TTTTkkkk____CCCCrrrreeeeaaaatttteeeeEEEErrrrrrrroooorrrrHHHHaaaannnnddddlllleeeerrrr; disobey it at
your own risk.
TTTTkkkk____DDDDeeeelllleeeetttteeeeEEEErrrrrrrroooorrrrHHHHaaaannnnddddlllleeeerrrr may be called to delete a previously-
created error handler. The _h_a_n_d_l_e_r argument identifies the
error handler, and should be a value returned by a previous
call to TTTTkkkk____CCCCrrrreeeeaaaatttteeeeEEEEvvvveeeennnnttttHHHHaaaannnnddddlllleeeerrrr.
A particular error handler applies to errors resulting from
protocol requests generated between the call to
TTTTkkkk____CCCCrrrreeeeaaaatttteeeeEEEErrrrrrrroooorrrrHHHHaaaannnnddddlllleeeerrrr and the call to TTTTkkkk____DDDDeeeelllleeeetttteeeeEEEErrrrrrrroooorrrrHHHHaaaannnnddddlllleeeerrrr.
However, the actual callback to _p_r_o_c may not occur until
after the TTTTkkkk____DDDDeeeelllleeeetttteeeeEEEErrrrrrrroooorrrrHHHHaaaannnnddddlllleeeerrrr call, due to buffering in
the client and server. If an error event pertains to a
protocol request made just before calling
TTTTkkkk____DDDDeeeelllleeeetttteeeeEEEErrrrrrrroooorrrrHHHHaaaannnnddddlllleeeerrrr, then the error event may not have
been processed before the TTTTkkkk____DDDDeeeelllleeeetttteeeeEEEErrrrrrrroooorrrrHHHHaaaannnnddddlllleeeerrrr call. When
this situation arises, Tk will save information about the
handler and invoke the handler's _p_r_o_c later when the error
event finally arrives. If an application wishes to delete
an error handler and know for certain that all relevant
errors have been processed, it should first call
TTTTkkkk____DDDDeeeelllleeeetttteeeeEEEErrrrrrrroooorrrrHHHHaaaannnnddddlllleeeerrrr and then call XXXXSSSSyyyynnnncccc; this will flush
out any buffered requests and errors, but will result in a
performance penalty because it requires communication to and
from the X server. After the XXXXSSSSyyyynnnncccc call Tk is guaranteed
not to call any error handlers deleted before the XXXXSSSSyyyynnnncccc